Reliable delivery of multi-cast conferencing data

ABSTRACT

Conferencing data is reliably delivered to computer systems participating in a hierarchically arranged multi-cast conferencing session. When a child computer system does not receive a multi-cast packet (e.g., an IP multi-cast packet), the child computer system sends a negative acknowledgment to a parent computer system. In response, the parent computer system re-transmits conferencing data that was contained in the multi-cast packet to the child computer system. Conferencing data can be re-transmitted to the child computer system via uni-cast (e.g., TCP). Accordingly, conferencing data that is not received or that is damaged via multi-cast can be repaired via uni-cast. Computer systems can join an existing multi-cast conference session without having to communicate with the root computer system. The root computer system adjusts a multi-cast send rate to compensate for changed network conditions.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of and claims benefit to U.S. patentapplication Ser. No. 12/356,096 which was filed Jan. 20, 2009 and whichis a divisional and claims benefit to U.S. patent application Ser. No.10/436,613 which was filed May 13, 2003.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates to network communication technology, andmore specifically, to reliable delivery of multi-cast conferencing data.

2. Background

Computer networks have enhanced our ability to communicate and accessinformation by allowing one computer or device (hereinafter bothreferred to as a “computing system”) to communicate over a network withanother computing system using electronic messages. When transferring anelectronic message between computing systems, the electronic messagewill often pass through a protocol stack that performs operations on thedata within the electronic message (e.g., packetizing, routing, flowcontrol). The Open System Interconnect (“OSI”) model is an example of anetworking framework for implementing a protocol stack.

The OSI model breaks down the operations for transferring an electronicmessage into seven distinct “layers,” each designated to perform certainoperations in the data transfer process. While protocol stacks canpotentially implement each of the layers, many protocol stacks implementonly selective layers for use in transferring data across a network.When data is transmitted from a computing system, it originates at theapplication layer and is passed down to intermediate lower layers andthen onto a network. When data is received from a network it enters thephysical layer and is passed up to higher intermediate layers and theneventually received at the application layer. The application layer, theupper most layer, is responsible for supporting applications andend-user processes, such as, for example, electronic conferencingsoftware.

Often, when two computing systems are to communicate with each other,the two computing systems will first establish a connection (e.g., aTransmission Control Protocol (“TCP”) connection). Thus, when a numberof different computing systems are to participate in an electronicconference, the different computing systems may establish connectionsamong one another. Accordingly, each computing system participating inthe electronic conference is then able to share conference data withevery other computing system participating in the electronic conference.The established connections can result in the computing systems beingconfigured in a logical hierarchy, such as, for example, that of a T.120conferencing session. A logical hierarchy can include a root computingsystem having connections to one or more intermediate computing systems,that are in turn eventually connected to one or more leaf computingsystems (potentially through connections to one or more otherintermediate computing systems). Accordingly, a logically hierarchy caninclude a significant number of established connections.

During an electronic conference, conferencing data typically originatesat an intermediate or leaf computing system in one branch of the logicalhierarchy. The intermediate or leaf computing system transfers theconferencing data up the logical hierarchy (e.g., by established TCPconnections) to the root computing system. The root computing, systemthen transfers the conferencing data down the logical hierarchy (e.g.,by utilizing established TCP connections) to all the intermediate andleaf computing systems in the logical hierarchy. Accordingly, forconferencing data to reach an intermediate or leaf computing system theconferencing data may travel over a number of established connections.For example to deliver conferencing data to a leaf computing system, theconferencing data may travel over first connection between a rootcomputing system and a first intermediate computing system, over secondconnection between the first intermediate computing system and a secondintermediate computing system, and over a third connection between thesecond intermediate computing system and the leaf computing system.

Many connection-oriented protocols, such as TCP, provide the features ofend-to-end error recovery, resequencing, and flow control. Accordingly,utilizing a connection-oriented protocol to transfer conferencing dataincreases reliability. However, to realize the features ofconnection-oriented protocols, state information, such as, for example,send and receive buffers, congestion control parameters, and sequenceand acknowledgment number parameters must be maintained for each TCPconnection. Further, some state information must be transferred alongwith conferencing data when conferencing data is transferred betweencomputing systems. Maintenance and transfer of state informationconsumes computing system resources (e.g., system memory), consumesnetwork bandwidth, and potentially increases network latency. In anelectronic conference with a number of intermediate and leaf computingsystems the bandwidth consumed by transferred state information can berelatively large.

As a result, some electronic conferencing applications have utilizedmulti-cast protocols (e.g., multi-cast Internet Protocol (“IP”)) totransfer conferencing data from a root computing system down to othercomputing systems in a logically hierarchy. In electronic conferencesutilizing multi-cast protocols, each intermediate and leaf computingsystem listens on the same designated multi-cast address forconferencing data. Accordingly, a root computing system need onlytransmit conferencing data to the designated multi-cast address todeliver the conferencing data to all the other computing systems. Duringnormal operation, each computing system listening on the designatedmulti-cast address will then receive the conferencing data.

However, since multi-cast protocols are typically notconnection-oriented, multi-cast protocols do not provide any reliablemessaging features (e.g., end-to-end error recovery, resequencing, flowcontrol, etc). Thus, when multi-cast data is lost or damaged there islittle, if anything, that can be done to recover the lost or damageddata. This is unfortunate, since lost or damaged conferencing data cansignificantly reduce the usefulness of an electronic conference.Further, since multi-cast conferencing data is transmitted to everycomputer system, lost or damaged multi-cast conferencing data canpotentially affect every intermediate and leaf computing systemparticipating in the electronic conference. Therefore systems, methods,computer program products, and data structures for reliably deliveringmulti-cast conferencing data would be advantageous.

BRIEF SUMMARY OF THE INVENTION

The foregoing problems with the prior state of the art are overcome bythe principles of the present invention, which are directed towardsmethods, systems, and computer program products for reliable delivery ofmulti-cast conferencing data. A number of computer systems participatein a hierarchically arranged multi-cast conference session that includesat least a parent computer system and one or more corresponding childcomputer systems. The parent computer system (which may or may not be aroot computer system) accesses a multi-cast packet (e.g., an InternetProtocol (“IP”) multi-cast packet) containing conferencing data for themulti-cast conference session. The parent computer system stores theconferencing data in a receive buffer until receiving an acknowledgmentfrom each of one or more corresponding child computer systems indicatingreception of the conferencing data.

A child computer system detects, for example, by utilizing sequencenumbers, that the child computer system did not receive the multi-castpacket. The child computer system sends a negative acknowledgementmessage to the parent computer system to indicate that the multi-castpacket was not received. In response, the parent computer systemidentifies a mechanism for re-transmitting the stored conferencing datato the child computer system. When the parent computer system is theroot computer system, the parent computer system may identify amulti-cast or a uni-cast mechanism (e.g., utilizing a TransmissionControl Protocol (“TCP”) connection) for re-transmitting theconferencing data.

On the other hand, when the parent computer system is not the rootcomputer system, the parent computer system can identify a uni-castmechanism. Thus, conferencing data can be re-transmitted to a childcomputer system via uni-cast when it is indicated that a multi-castpacket is not received. Accordingly, embodiments of the presentinvention can more reliably deliver conferencing data through recoveryvia connection-oriented protocols, while still realizing potentialbandwidth savings and reduced latency associated with multi-castprotocols. Further, embodiments of the present invention allow bothmulti-cast capable computer systems and computers that are notmulti-cast enabled to participate in the same conferencing session.Multi-cast capable computer systems can participate in the conferencingsession via multi-cast and computers that are not multi-cast enabled canparticipate in the conferencing session via uni-cast.

In some embodiments, a parent computer system invites a child computersystem to join an existing multi-cast conference session. The parentcomputer system access a multi-cast address for the multi-castconference session and transmits a multi-cast invite message, includingat least the multi-cast address, to the child computer system. Inresponse to the multi-cast invite, the child computer system sends amulti-cast status message indicating to the parent computer system thecapability to receive multi-cast packets, in response to the multi-caststatus message, the parent computer system sends a next multi-castsequence number to the child computer system. The next multi-castsequence number indicates the multi-cast sequence number that is to beassociated with the next multi-cast packet received at the childcomputer system. Accordingly, the child computer system can dynamicallyjoin an existing multi-cast conference session without significantlyimpacting other computer systems already participating in the existingmulti-cast conference session.

From time to time, a root computer system can adjust a current send ratefor multi-cast packets. When the root computer system's immediate childcomputer systems acknowledge reception of a sequence of multi-castpackets within a specified period of time, a current send rate can beincreased. On the other hand, when the immediate child computer systemsdo not acknowledge reception of a sequence of multi-cast packets withina specified period of time (e.g., as a result of network congestion orlatency), the send rate of multi-cast packets can be decreased.Accordingly, a root computer system can adjust a send rate to compensatefor changes in the transmission characteristics (e.g., availablebandwidth and latency) of networks used to deliver multi-cast packets.

Additional features and advantages of the invention will be set forth inthe description that follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 illustrates a suitable operating environment for the principlesof the present invention.

FIG. 2 illustrates an example of a network architecture that facilitatesdelivery of multi-cast conferencing data with increased reliability.

FIG. 3 illustrates an example flowchart of a method for joining anexisting multi-cast conference session.

FIG. 4 illustrates an example flowchart of a method for more reliablydelivering multi-cast conferencing data.

FIG. 5 illustrates an example flowchart of a method for adjusting amulti-cast send rate.

FIG. 6 illustrates an example protocol stack that facilitatesappropriate synchronization of uni-cast and multi-cast sequencingnumbers.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The principles of the present invention provide for reliably deliveringmulti-cast conferencing data to computer systems participating in amulti-cast conference session. When multi-cast conferencing data is lostor damaged during delivery, the lost or damaged conferencing data can berepaired via connection-oriented uni-cast delivery. Computer systems canjoin an existing multi-cast conference session without significantlyimpacting other computer systems already participating in the existingmulti-cast conference session. A root computer system can adjust amulti-cast send rate to compensate for changed network conditions.

Embodiments within the scope of the present invention includecomputer-readable media for carrying or having computer-executableinstructions or data structures stored thereon. Such computer-readablemedia may be any available media, which is accessible by ageneral-purpose or special-purpose computer system. By way of example,and not limitation, such computer-readable media can comprise physicalstorage media such as RAM, ROM, EPROM, CD-ROM or other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother media which can be used to carry or store desired program codemeans in the form of computer-executable instructions, computer-readableinstructions, or data structures and which may be accessed by ageneral-purpose or special-purpose computer system.

In this description and in the following claims, a “network” is definedas one or more logical communication links that enable the transport ofelectronic data between computer systems and/or modules. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a computer system, the connection isproperly viewed as a computer-readable medium. Thus, any such connectionis properly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of computer-readable media.Computer-executable instructions comprise, for example, instructions anddata which cause a general-purpose computer system or special-purposecomputer system to perform a certain function or group of functions. Thecomputer executable instructions may be, for example, binaries,intermediate format instructions such as assembly language, or evensource code.

In this description and in the following claims, a “computer system” isdefined as one or more software modules, one or more hardware modules,or combinations thereof, that work together to perform operations onelectronic data. For example, the definition of computer system includesthe hardware components of a personal computer, as well as softwaremodules, such as the operating system of the personal computer. Thephysical layout of the modules is not important. A computer system mayinclude one or more computers coupled via a network. Likewise, acomputer system may include a single physical device (such as a mobilephone or Personal Digital Assistant “PDA”) where internal modules (suchas a memory and processor) work together to perform operations onelectronic data.

In this description and in the following claims, a “logicalcommunication link” is defined as any communication path that enablesthe transport of electronic data between two entities such as computersystems or modules. The actual physical representation of acommunication path between two entities is not important and may changeover time, such as, for example, when a routing path is changed. Alogical communication link can include portions of a system bus, a localarea network, a wide area network, the Internet, combinations thereof,or portions of any other path that facilitates the transport ofelectronic data. Logical communication links are defined to includehardwired links, wireless links, or a combination of hardwired links andwireless links. Logical communication links can also include software orhardware modules that condition or format portions of data so as to makethe portions of data accessible to components that implement theprinciples of the present invention proxies, routers, gateways, etc).

In this description and in the following claims, “conferencing data” isdefined as data associated with an electronic conference. Conferencingdata can be transferred between computer systems participating in theelectronic conference. Conferencing data is defined to include audioand/or video streams, visual and/or non-visual data, and/or data filesthat are delivered from a sending computer system (e.g., a root computersystem) to a receiving computer system (e.g., an intermediate or leafcomputer system). For example, conferencing data can include voice overInternet Protocol (“IP”) data (audio stream data), camera video data(video stream data), application sharing and whiteboard data (visualdata), chat text data (non-visual data), and/or file transfer data (datafile). Conferencing data can be transferred using a wide variety ofprotocols or combination of protocols, such as, for example, InternetProtocol (“IP”), User Datagram Protocol (“UDP”), Transmission ControlProtocol (“TCP”), Real-Time Transport Protocol (“RTP”), and Real TimeStreaming Protocol (“RTSP”).

In this description and in the following claims, “send rate” is definedas the speed with which conferencing data is transferred (or is to betransferred) onto a logical communication link, across a logicalcommunication link, or received from a logical communication link. Asend rate can be measured in a variety of different units, such as, forexample, Megabits per second (“Mbps”) and Megabytes per second (“MBps”).

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, laptop computers,hand-held devices, multi-processor systems, microprocessor-based orprogrammable consumer electronics, network PCs, minicomputers, mainframecomputers, mobile telephones, PDAs, pagers, and the like. The inventionmay also be practiced in distributed system environments where local andremote computer systems, which are linked (either by hardwired links,wireless links, or by a combination of hardwired and wireless links)through a network, both perform tasks. In a distributed systemenvironment, program modules may be located in both local and remotememory storage devices.

FIG. 1 and the following discussion are intended to provide a brief,general description of a suitable computing environment in which theinvention may be implemented. Although not required, the invention willbe described in the general context of computer-executable instructions,such as program modules, being executed by computer systems. Generally,program modules include routines, programs, objects, components, datastructures, and the like, which perform particular tasks or implementparticular abstract data types. Computer-executable instructions,associated data structures, and program modules represent examples ofthe program code means for executing acts of the methods disclosedherein.

With reference to FIG. 1, an example system for implementing theinvention includes a general-purpose computing device in the form ofcomputer system 120, including a processing unit 121, a system memory122, and a system bus 123 that couples various system componentsincluding the system memory 122 to the processing unit 121. Processingunit 121 can execute computer-executable instructions designed toimplement features of computer system 120, including features of thepresent invention. The system bus 123 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. Thesystem memory includes read only memory (“ROM”) 124 and random accessmemory (“RAM”) 125. A basic input/output system (“BIOS”) 126, containingthe basic routines that help transfer information between elementswithin computer system 120, such as during start-up, may be stored inROM 124.

The computer system 120 may also include magnetic hard disk drive 127for reading from and writing to magnetic hard disk 139, magnetic diskdrive 128 for reading from or writing to removable magnetic disk 129,and optical disk drive 130 for reading from or writing to removableoptical disk 131, such as, or example, a CD-ROM or other optical media.The magnetic hard disk drive 127, magnetic disk drive 128, and opticaldisk drive 130 are connected to the system bus 123 by hard disk driveinterface 132, magnetic disk drive-interface 133, and optical driveinterface 134, respectively. The drives and their associatedcomputer-readable media provide nonvolatile storage ofcomputer-executable instructions, data structures, program modules, andother data for the computer system 120. Although the example environmentdescribed herein employs magnetic hard disk 139, removable magnetic disk129 and removable optical disk 131, other types of computer readablemedia for storing data can be used, including magnetic cassettes, flashmemory cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs,and the like.

Program code means comprising one or more program modules may be storedon hard disk 139, magnetic disk 129, optical disk 131, ROM 124 or RAM125, including an operating system 135, one or more application programs136, other program modules 137, and program data 138. A user may entercommands and information into computer system 120 through keyboard 140,pointing device 142, or other input devices (not shown), such as, forexample, a microphone, joy stick, game pad, scanner, or the like. Theseand other input devices can be connected to the processing unit 121through input/output interface 146 coupled to system bus 123.Input/output interface 146 logically represents any of a wide variety ofdifferent interfaces, such as, for example, a serial port interface, aPS/2 interface, a parallel port interface, a Universal Serial Bus(“USB”) interface, or an Institute of Electrical and ElectronicsEngineers (“IEEE”) 1394 interface (i.e., a FireWire interface), or caneven logically represent a combination of different interfaces.

A monitor 147 or other display device is also connected to system bus123 via video interface 148. Speakers 169 or other audio output deviceis also connected to system bus 123 via audio interface 149. Otherperipheral output devices (not shown), such as, for example, printers,can also be connected to computer system 120.

Computer system 120 is connectable to networks, such as, for example, anoffice-wide or enterprise-wide computer network, a home network, anintranet, and/or the Internet. Computer system 120 can exchange datawith external sources, such as, for example, remote computer systems,remote applications, and/or remote databases over such networks.

Computer system 120 includes network interface 153, through whichcomputer system 120 receives data from external sources and/or transmitsdata to external sources. As depicted in FIG. 1, network interface 153facilitates the exchange of data with remote computer system 183 vialogical communication link 151. Network interface 153 can logicallyrepresent one or more software and/or hardware modules, such as, forexample, a network interface card and corresponding Network DriverInterface Specification (“NDIS”) stack. Logical communication link 151represents a portion of a network (e.g., an Ethernet segment), andremote computer system 183 represents a node of the network. Forexample, remote computer system 183 can be computer system thattransmits conferencing to computer system 120. On the other hand, remotecomputer system 183 can be a receiving computer system that receivesconferencing from computer system 120.

Likewise, computer system 120 includes input/output interface 146,through which computer system 120 receives data from external sourcesand/or transmits data to external sources. Input/output interface 146 iscoupled to modem 154 (e.g., a standard modem, a cable modem, or digitalsubscriber line (“DSL”) modem) via logical communication link 159,through which computer system 120 receives data from and/or transmitsdata to external sources. As depicted in FIG. 1, input/output interface146 and modern 154 facilitate the exchange of data with remote computersystem 193 via logical communication link 152. Logical communicationlink 152 represents a portion of a network and remote computer system193 represents a node of the network. For example, remote computersystem 193 can be a computer system that transmits conferencing data tocomputer system 120. On the other hand, remote computer system 193 canbe computer system that receives conferencing data from computer system120.

While FIG. 1 represents a suitable operating environment for the presentinvention, the principles of the present invention may be employed inany system that is capable of, with suitable modification if necessary,implementing the principles of the present invention. The environmentillustrated in FIG. 1 is illustrative only and by no means representseven a small portion of the wide variety of environments in which theprinciples of the present invention may be implemented.

FIG. 2 illustrates example network architecture 200. The computersystems in network architecture 200 are connected to one another bylogical communication links 241-247 (hereinafter referred to simply as“links”), resulting in the depicted hierarchical configuration, such as,for example, that of a T.120 electronic conference. Accordingly, somecomputer systems are viewed as parent computer systems of other computersystems. For example, root computer system 202 can be viewed as a parentcomputer system of intermediate computer systems 212 and 213. On theother hand, some computer systems are viewed as child computer systemsof other computers systems. For example, leaf computer systems 222, 223,and 224 can be viewed as child computer systems of intermediate computersystem 212. Similarly, leaf computer systems 226 and 227 can be viewedas child computer systems of intermediate computer system 213.

Some computer systems are viewed as both child computer systems andparent computer systems. For example, intermediate computer system 212can be viewed as a child of root computer system 202 and a parentcomputer system of leaf computer systems 222, 223, and 224. Similarly,intermediate computer system 213 can be viewed as a child of rootcomputer system 202 and a parent computer system of leaf computersystems 226 and 227.

The computer systems depicted within conference boundary 271 (the solidline) are participating in electronic conference 270. Of theparticipating computer systems, those depicted within multi-castboundary 251 (the dashed line) are participating in multi-cast session250 and can receive conferencing data (for electronic conference 270)that has been multi-cast (e.g., IP multi-cast). Root computer system 202can allocate a designated multi-cast address (e.g., an IP multi-castaddress) as a destination network address for multi-cast packetscontaining conferencing data. When a computer system joins multi-castsession 250, the joining computer system is made of aware of thedesignated multi-cast address. Accordingly, the joining computer systemcan listen on the designated multi-cast address for multi-cast packetscontaining conferencing data. For example, intermediate computer systems212 and 213 and leaf computer systems 223, 224, and 226 can listen on adesignated multi-cast address for multi-cast packets from root computersystem 202. As depicted by arrows 261-265, multi-cast packet 282, whichcontains conferencing data 252, is multi-cast to intermediate computersystems 212 and 213 and leaf computer systems 223, 224, and 226.

Other participating computer systems, such as, for example, computersystems that do not support multi-cast, can participate in electronicconference 270 via uni-cast. For example, intermediate computer system213 and leaf computer system 227 may communicate via a TCP connection.Accordingly, after receiving multi-cast packet 282, intermediatecomputer system 213 can extract conferencing data 252. Intermediatecomputer system 213 can then include conferencing data 252 in TCP packet283 for delivery to leaf computer system 227. As depicted by arrow 266,intermediate computer system 213 can delivery TCP packet 266 to leafcomputer system 227.

FIG. 3 illustrates an example flow chart of a method 300 for joining anexisting multi-cast session. The method 300 will be described withrespect to the computer systems in network architecture 200.

The method 300 includes an act of accessing a designated multi-castaddress for a multi-cast session (act 301). Act 301 can include anintermediate computer system, such as, for example, intermediatecomputer system 212, identifying an IP multi-cast address currentlybeing used by the intermediate computer system. Alternatively, a rootcomputer system, such as, for example, root computer system 202, canallocate an IP multi-cast network address. An allocated IP multi-castaddress may be an IP address from a reserved range of IP address, suchas, for example, between 224.0.0.0 and 239.255.255.255. An IP multi-castaddress can be allocated using an allocation protocol, such as, forexample, Multicast Dynamic Client Allocation Protocol (“MDHCP”).

An IP multi-cast address can be allocated sequentially or randomly froma range of IP multi-cast addresses supplied by an administrator. Beforeallocating an IP multi-cast address, a root computer system can performa check to determine if the IP multi-cast address is already in use(e.g., by an existing multi-cast session). To reduce the negativeimpacts associated with a plurality of computer systems allocating thesame IP multi-cast address, an IP multi-cast address and a root computersystem's IP address can be combined to form a unique identifier for amulti-cast session. When a multi-cast packet is received, a receivingcomputer system checks both the IP multi-cast address and root computersystem's IP address. When the check determines that the multi-castpacket is for a multi-cast session the receiving computer system is notparticipating in, the multi-cast packet can be discarded.

The method 300 includes an act of sending a multi-cast invite message,including at least the designated multi-cast address, to the childcomputer system (act 302). Act 302 can include a parent computer system,such as, for example, intermediate computer system 212, sending amulti-point communication service (“MCS”) Connect-Initial message to achild computer system, such as, for example, leaf computer system 222. Amulti-cast invite message can include a session identifier datastructure representing the designated multi-cast address, a designatedmulti-cast port, and a network address of the multi-cast sender, suchas, for example, an IP address of root computer system 202. One of thefields of the session identifier data structure can represent adesignated multi-cast address for a multi-cast session. Another field ofthe session identifier data structure can represent a designated portfor the multi-cast session. Yet another field of the data structure canrepresent a network address of the multi-cast sender.

The method 300 includes an act of receiving a multi-cast invite message,including at least the designated multi-cast address, from the parentcomputer system (act 305). For example, leaf computer system 222 canreceive the multi-cast invite message sent from intermediate computersystem 212. A received multi-cast invite message can include a sessionidentifier, for example, represented in a session identifier datastructure. When a child computer system receives a session identifierdata structure, the child computer system can maintain the fields of thesession identifier data structure in memory. Accordingly, a childcomputer system can se a session identifier data structure to facilitateconfiguration of a network interface and for verifying that multi-castpackets are associated with a particular multi-cast session.

The method 300 includes an act of receiving a multi-cast packet at thedesignated multi-cast address (act 306). Act 306 can include receiving amulti-cast packet transmitted from the root computer system forreception by computer systems participating in a multi-cast session. Forexample, as indicated by arrow 267, leaf computer system 222 can receivemulti-cast packet 282. Reception of multi-cast packet 282 indicates toleaf computer system 222 that a received multi-cast invite messagecontained appropriate connection information (e.g., designatedmulti-cast address, designated multi-cast port, and network address ofroot computer system 202) for joining multi-cast session 250.

The method 300 includes an act of sending a multi-cast status messageindicating the capability to receive multi-cast packets (act 307). Act307 can include a child computer system sending a multi-cast statusmessage to a parent computer system in response to receiving amulti-cast packet. For example, in response to receiving multi-castpacket 282, leaf computer system 222 can send a multi-cast statusmessage to intermediate computer system 212. The multi-cast statusmessage can be an acknowledgment message acknowledging that leafcomputer system 222 received multi-cast packet 282.

The method 300 includes an act of receiving a multi-cast status messageindicating that the child computer system is capable of receivingmulti-cast packets (act 303). Act 303 can include a parent computersystem receiving a multi-cast status message indicating that the childcomputer system can receive multi-cast packets for the multi-castsession. For example, intermediate computer system 212 can receive amulti-cast status message from leaf computer system 222. A receivedmulti-cast status message can be an acknowledgment message acknowledgingthat leaf computer system 222 received multi-cast packet 282. Sinceintermediate computer system 212 also receives multi-cast packet 282,intermediate computer system 212 can verify that a received multi-caststatus message is appropriate (e.g., that the multi-cast packet wasreceived at the designated multi-cast address and port, etc.).

The method 300 includes an act of sending a next multi-cast sequencenumber to the child computer system (act 304). Act 304 can include aparent computer system sending a next multi-cast sequence number tochild computer system in response to receiving a multi-cast statusmessage. For example, intermediate computer system 212 can send amulti-cast invite-confirm message including the next multi-cast sequencenumber to leaf computer system 222 in response to leaf computer system222 acknowledging receipt of multi-cast packet 282. The next multi-castsequence number can indicate the sequence number that is to beassociated with the next multi-cast packet for multi-cast session 250.

The method 300 includes an act of receiving a next multi-cast sequencenumber from the parent computer system (act 308). Act 308 can include achild computer system receiving a next multi-cast sequence number from aparent computer system. For example, leaf computer system 222 canreceive a multi-cast invite-confirm message including the nextmulti-cast sequence number from intermediate computer system 212. Thenext-multi-cast sequence number indicates to leaf computer system 222the sequence number that is to be associated with the next multi-castpacket for multi-cast session 250. Accordingly, leaf computer system 222can begin to indicate to intermediate computer system 212 whenmulti-cast packets are not received.

When leaf computer system 222 joins multi-cast session 250, bothmulti-cast session boundary 251 and a conference boundary 271 can beexpanded to include leaf computer system 222. This expansion iscollectively represented by expanded conference boundary 273 (the dottedline). Leaf computer system 222 joins both multi-cast session 250 andelectronic conference 270 without ever sending data to root computersystem 202. Further, little, if any, resources are expended at rootcomputer system 202 as a result of leaf computer system joining.Accordingly, leaf computer system 222 joins multi-cast session 250 (anexisting multi-cast session) without significantly impacting othercomputer systems already participating in multi-cast session 250.

FIG. 4 illustrates an example flow chart of a method 400 for morereliable delivery of multi-cast conferencing data. The method 400 willbe described with respect to the computer systems in networkarchitecture 200.

The method 400 includes an act of accessing a multi-cast packetcontaining conferencing data (act 401). Act 401 can include accessing amulti-cast packet that includes conferencing data for a multi-castsession. The multi-cast packet can be a multi-cast packet that wasoriginally multi-cast by a root computer system for delivery to othercomputer systems participating in the multi-cast session. A multi-castpacket can be accessed by a root computer system, an intermediatecomputer system, or a leaf computer system participating in themulti-cast session. For example, within multi-cast session 250, rootcomputer system 202, intermediate computer system 212, or intermediatecomputer system 213 can access multi-cast packet 282.

Accessing a multi-cast packet can include accessing conferencing datacontained in the multi-cast packet. For example, root computer system202 may access conferencing data 252 before transmitting multi-castpacket 282 to computer systems participating in multi-cast session 250.Intermediate computer system 212 and intermediate computer system 213can access conferencing data 252 after they receive multi-cast packet282.

The method 400 includes an act of storing conferencing data in a receivebuffer (act 402). Act 402 can include a root computer system orintermediate computer system storing accessed conferencing data in areceive buffer. For example within multi-cast session 250, root computersystem 202, intermediate computer system 212 and/or intermediatecomputer system 213, can store conferencing data 252 in a receivebuffer. It may be that parent computer system simultaneously storesconferencing data from a plurality of multi-cast packets.

Conferencing data can remain stored in a receive buffer (e.g., in systemmemory) until all of a computer system's corresponding multi-castsession child computer systems acknowledge receipt of the conferencingdata. For example, intermediate computer system 213 can storeconferencing data 252 until leaf computer system 226 acknowledgesreceipt of conferencing data 252. Since leaf computer system 227 isparticipating in electronic conference 270 via uni-cast, leaf computersystem 227 will not acknowledge receipt of conferencing data 252.Conferencing data can be flushed (removed) from a receive buffer afterreceiving appropriate acknowledgments from corresponding child computersystems. For example, after receiving acknowledgments from leaf computersystem 226 and leaf computer 227, intermediate computer system 213 canflush conferencing data 252 from a corresponding receive buffer.

The method 400 includes an act of receiving a last continuously receivedmulti-cast packet (Act 406). Act 406 can include an intermediate or leafcomputer system receiving a last continuously received multi-castpacket. For example, any of the computer systems participating inmulti-cast session 250 can receive a last continuously receivedmulti-cast packet transmitted from root computer system 202.

An ACK window parameter value can be maintained at a parent computersystem to schedule the transmission acknowledgment messages from childcomputer systems. An ACK window parameter value indicates to childcomputer systems the number of multi-cast packets that are to bereceived between acknowledgment messages. An ACK window parameter valuecan change dynamically as child computer systems connect to anddisconnect from the parent computer system. An ACK window parametervalue can be configured such that the likelihood of an acknowledgmentimplosion at the parent computer system is reduced.

For example, for a parent computer system having “in” children computersystems, an ACK window parameter value “N” can be configured accordingto the equation (N/2)<=m<=N. Thus, for a parent computer system having 5child computer systems, an ACK window parameter value of 5, 6, 7, 8, 9,or 10 may be selected. If 7 were selected, this would indicate to achild computer system that the child computer system is to send anacknowledgement message to the parent computer system after thereception of every 7 multi-cast packets. Child computer systems canrandomly select a first multi-cast packet for acknowledgment to furtherreduce the likelihood of an acknowledgment implosion at the parentcomputer system.

As multi-cast packets are transmitted to computer systems participatingin a multi-cast session, each multi-cast packet is assigned a sequencenumber. Different multi-cast packets can be assigned different sequencenumbers so that the different multi-cast packets can be distinguishedfrom one another. For example, sequence numbers can be assignedincremental (e.g., by adding one) so that a subsequent multi-cast packetcan be distinguished from prior multi-cast packet. Upon reaching amaximum sequence number, assigned sequence numbers may “roll-over” andbegin at zero. Sequence numbers can be used to indicate a packetordering to a receiving computer system. Table 1 contains an examplesequence of multi-cast packets for an ACK window parameter value of 5.

TABLE 1 Order of Receipt Packet Sequence Number 1 Multi-cast Packet A 42 Multi-cast Packet B 6 3 Multi-cast Packet C 5 4 Multi-cast Packet D 85 Multi-cast Packet E 7

Although received in an order that differs from corresponding sequencenumbers, a receiving computer system can use the sequence numbers toappropriately re-order the multi-cast packets after reception. Forexample, a receiving computer system could re-order the sequence ofmulti-cast packets in the following order: Multi-cast Packet A,Multi-cast Packet C, Multi-cast Packet B, Multi-cast Packet E,Multi-cast Packet D. Accordingly, Multi-cast Packet D can be viewed as alast continuously received multi-cast packet.

When no conferencing data is multi-cast for a specified time threshold,a root computer system can multi-cast a keep alive message having anappropriate sequence number (e.g., incremented form the last sequencenumber). Computer systems participating in a multi-cast session canacknowledge receipt of a keep alive message by sending an acknowledgmentmessage to a corresponding parent computer system. Acknowledgment of akeep alive message indicates to a parent computer system that acorresponding child computer system is still capable of receivingmulti-cast packets for the multi-cast session. For example, leafcomputer system 226 can send an acknowledge message to intermediatecomputer system 213 to indicate continued capability to receivedmulti-cast packets for multi-cast session 250.

When a parent computer system receives acknowledgment messages from allcorresponding child computer systems, the parent computer system can inturn acknowledge receipt of the keep alive message to its parentcomputer system. Acknowledgments can continue up a hierarchical tree toa root computer system. For example, upon receiving acknowledgementmessages from each of leaf computer systems 222, 223, and 224,intermediate computer system 212 can in turn send an acknowledgmentmessage to root computer system 202. Keep alive messages can be sent outat specified keep-alive intervals. Keep alive intervals can be definedusing exponential increases, such as, for example, 2 sec., 4 sec., 8sec., 16 sec., etc. After a busy time, a keep alive interval can bedecreased. On the other hand, after longer periods of idle time a keepalive interval can be increased.

The method 400 includes an act of receiving a last received multi-castpacket (act 407). Act 407 can include an intermediate or leaf computersystem receiving a last received multi-cast packet. For example, any ofthe computer systems participating in multi-cast session 250 can receivea last received multi-cast packet multi-cast from root computer system202. Table 2 contains a second example sequence of multi-cast packetsfor an ACK window parameter value of 6.

TABLE 2 Order of Receipt Packet Sequence Number 1 Multi-cast Packet F 152 Multi-cast Packet G 16 3 Multi-cast Packet H 17 4 Multi-cast Packet I18 5 Multi-cast Packet J 21 6 Multi-cast Packet K 23

Table 2 indicates that a last received packet was Multi-cast Packet K.

The method 400 includes an act of detecting that one or more multi-castpackets were not received (act 408). Act 408 can include detecting thatone or more multi-cast packets with sequences between the lastcontinuously received multi-cast packet and the last received multi-castpacket were not received. For example, referring back to Table 2,Multi-cast Packet I can be viewed as a last continuously receivedmulti-cast packet and Multi-cast Packet K can be viewed as a lastreceived multicast packet. Accordingly, a computer system participatingin a multi-cast session may detect that multi-cast packets correspondingto multi-cast sequence numbers 19, 20, and 22 were not received.

The method 400 includes an act of sending a negative acknowledgmentmessage to a parent computer system (act 409). Act 409 can include achild computer system sending a negative acknowledgment message thatindicates the child computer system did not receive one or moremulti-cast packets having multi-cast sequence numbers between the lastcontinuously received multi-cast packet and the last received multi-castpacket. For example, when appropriate, leaf computer system 222 can senda negative acknowledgment message to intermediate computer system 212indicating that leaf computer system 222 did not receive one or moremulti-cast packets for multi-cast session 250. Similarly, whenappropriate, intermediate computer system 212 can send a negativeacknowledgment message to root computer system 202 indicating thatintermediate computer system 212 did not receive one or more multi-castpackets for multi-cast session 250.

A sent negative acknowledgment message can include a data structurerepresenting the packet sequence number of the last continuouslyreceived multi-cast packet, the packet sequence number of the lastreceived multi-cast packet, and a hit map indicating received andmissing multi-cast packets between the last continuously multi-castpacket and the last received multi-cast packet. For example, aparticipating computer system that received the sequence of multi-castpackets in Table 2, could send a negative acknowledgement message withvalues of 18, 23, and a bit map indicating that 19, 20, 21, and 22 aresequence numbers of packets between 18 and 23 and that 19, 20, and 22are marked as missing packets. Accordingly, a child computer systemprovides repair information that can be used by a corresponding parentcomputer system to replace conferencing data that was not receivedand/or repair damaged conferencing data.

The method 400 includes an act of detecting that a child computer systemdid not sufficiently receive a multi-cast packet (act 403). Act 403 caninclude a parent computer system receiving a negative acknowledgmentmessage from a child computer system. For example, intermediate computersystems 212 may receive a negative acknowledgment message from leafcomputer system 222, leaf computer system 223, or leaf computer system224. Similarly, root computer system 202 may receive a negativeacknowledgment message from intermediate computer system 212 orintermediate computer system 213.

A received negative acknowledgment message can include repairinformation identifying conferencing data that was not received by achild computer system and/or potentially identifying damagedconferencing data. Repair information can be represented in a repairinformation data structure. One of the fields of the repair informationdata structure can represent the last continuously received multi-castpacket that was received by a child computer system. Another field ofthe repair information data structure can the last received multi-castpacket that was received by the child computer system. Yet another fieldof the repair information data structure can represent a bit map of anymulti-cast packets received between the last continuously multi-castpacket and the last received multi-cast packet received by the childcomputer system.

Accordingly, a parent computer system can use repair information toidentify that conferencing data was not sufficiently received at thechild computer system. A parent computer system can identify thatconferencing data was not sufficiently received when a multi-cast packetis not received at all by the child computer system (i.e., the packetwas lost). Alternatively, the parent computer system can identify thatconferencing data was not sufficiently received when the parent computersystem determines that conferencing data received at the child computersystem was damaged.

Packet loss can be detected from received repair information. Referringback to Table 2, a parent computer system could identify from a receivedbit map that a child computer system did not receive multi-cast packetshaving sequence numbers 19, 20, and 22.

In some embodiments, a parent computer system detects that a childcomputer system did not receive a one or more multi-cast packets when anacknowledgment message is not received after a number of packetsindicated by an ACK window parameter value. For example, when an ACKwindow parameter value is 7, a parent computer system should receive anacknowledgment message from a child computer system after every 7multi-cast packets. If after reception of a 7^(th) multi-cast packet,the parent computer system does not receive an acknowledgement messagethe parent computer system may determine that the child computer systemhas not received one or more multi-cast packets.

A parent computer system may wait a specified time threshold for anacknowledgment message. As depicted by arrows 261 and 262 multi-castpacket 282 is delivered to intermediate computer system 212 and leafcomputer system 224 respectively. When multi-cast packet 282 is the lastpacket in an ACK window, packet 282 can trigger an acknowledgmentmessage from leaf computer system 224. Upon receiving multi-cast packet282, intermediate computer system 212 will wait the specified timethreshold to receive an acknowledgment message from leaf computer system224. If an acknowledgment message is not received within the specifiedtime threshold, intermediate computer system 212 may determine that leafcomputer system 224 has not received one or more multi-cast packets.

A specified time threshold can be a round-trip time (“MT”) defined asthe allowable time difference in accepting a multi-cast packet between aparent computer system and a child computer system. When a root computersystem sends a multi-cast packet it records its local sending time.Subsequently, when a child computer system receives the multi-castpacket it records its local time. Then, when the child computer systemis ready to send an acknowledgment message, it records a local delaytime (e.g., for packet processing) inside the acknowledgement message.When the parent computer system receives the acknowledgment message itrecords the current time and the time elapsed since the parent computersystem sent the multi-cast packet. By subtracting the delay time at thechild computer system, the parent calculates the RTT to the childcomputer system. If the parent computer system is the root computersystem it will calculate the real RTT to the child computer system.

The method 400 includes an act of identifying a delivery mechanism forre-transmitting the stored conferencing data (act 404). Act 404 caninclude a parent computer system identifying a delivery mechanism forre-transmitting stored conferencing data to a child computer system. Forexample, it may be that intermediate computer system 212 identities adelivery mechanism for re-transmitting conferencing data 252 to leafcomputer system 222. Similarly, it may be that that root computer system202 identifies a delivery mechanism for re-transmitting conferencingdata 252 to intermediate computer system 212.

A delivery mechanism can be identified based at least on the parentcomputer system's position in a hierarchically arranged conferencingsession. An intermediate parent computer system can identify a uni-castmechanism, such as, for example, TCP, as a mechanism for re-transmittingstored conferencing data. For example, intermediate computer system 212can identify uni-cast as a mechanism for re-transmitting lost or damagedconferencing data to leaf computer system 222. However, a root computersystem (e.g., root computer system 202) may identify either a uni-castmechanism or a multi-cast mechanism for re-transmitting storedconferencing data.

When a threshold number of the root computer system's immediate childcomputer systems have lost conferencing data, the root computer systemcan determine that multi-cast is an appropriate mechanism forre-transmitting the conferencing data. An increased number of theimmediate child computer systems needing repair can be indicative of anincreased number of other computer systems lower in the hierarchy alsoneeding repair. That is, when some intermediate computer systems (e.g.,intermediate computer systems 212 and 213) have not received multi-castdata, there is an increased likelihood that other child computer systems(e.g., leaf computer systems 222, 223, 224, and 226) have also notreceived the multi-cast data. Accordingly, re-transmitting theconferencing data via multi-cast may be more efficient. For example,root computer system 202 can identify multi-cast as a mechanism forre-transmitting lost or damaged conferencing data to computer systemsparticipating in multi-cast session 250.

On the other hand, when less than the threshold number immediate childcomputer systems have lost conferencing data, the root computer systemcan determine that uni-cast is an appropriate mechanism forre-transmitting the conferencing data. A decreased number of theimmediate child computer systems needing repair can be indicative of areduced number of other computer systems lower in the hierarchy alsoneeding repair. That is, when a reduced number of intermediate computersystems (e.g., only intermediate computer systems 213) have not receivedmulti-cast data, it is likely that a reduced number of other childcomputer systems (e.g., only leaf computer system 226) have also notreceived the multi-cast data. Accordingly, re-transmitting theconferencing data via uni-cast may be more efficient. For example, rootcomputer system 202 can identify uni-cast as a mechanism forre-transmitting lost or damaged conferencing data to intermediatecomputer system 213.

The method 400 includes an act of re-transmitting the storedconferencing data according to the identified delivery mechanism (act405). Act 405 can include a parent computer system re-transmittingconferencing data from a receive buffer to the child computer system(e.g., via uni-cast or multi-cast). For example, intermediate computersystem 212 can re-transmit conferencing data (from a correspondingreceive buffer) to leaf computer system 222 via TCP. Alternately, rootcomputer system 202 can re-transmit conferencing data (from acorresponding receive buffer) to multi-cast session 250 via IPmulti-cast.

A protocol stack at a parent computer system can assign uni-castsequence numbers such that the uni-cast sequence numbers synchronizewith multi-cast sequence numbers of multi-cast packets. FIG. 6illustrates an example protocol stack 600 that facilitates thesynchronization of uni-cast and multi-cast sequence numbers. Protocolstack 600 includes transport layer 615, data framing layer 622, uni-castlayer 614, multi-cast layer 613 and application layer 611. Transportlayer 615 corresponds to a transport layer protocol, such as, forexample, TCP or User Datagram Protocol (“UDP”). Lower layers of protocolstack 600 (not shown) can receive packets from a network and transferthe packets up to transport layer 615. On the other hand, transportlayer 615 can receive packets from data framing layer 622 and transferpackets down to the lower layers for delivery onto the network. Dataframing layer 622 corresponds to a framing protocol, such as, forexample, X.224. Uni-cast and multi-cast packets can be framed usingsimilar types of framing headers, such as, for example, an X.224. Usingsimilar types of framing headers potentially makes recovery of missingpackets more efficient as both uni-cast and multi-cast packets can bebinary-identical.

Uni-cast layer 614 and multi-cast layer 613 operate together tosynchronize the transfer of packets to and from application layer 611.Application layer 611 corresponds to one or more application layerprocesses, such as, for example, Generic Conference Control (“GCC”)applications and/or T.120 applications. When a uni-cast packet, such as,for example, uni-cast packet 621, is transferred from transport layer615 towards application layer 611 the uni-cast packet may first bereceived by multi-cast layer 613. Similarly, when a uni-cast packet,such as, for example, uni-cast packet 622, is transferred fromapplication layer 611 towards transport layer 615, the uni-cast packetmay first be received by multi-cast layer 613.

Accordingly, multi-cast layer 613 can preserve the causality of packetssuch that the transfer of uni-cast repair packets (or the transfer ofuni-cast packets to computer systems that do not support multi-cast,such as, for example, leaf computer system 227) is appropriatelysynchronized with the transfer multi-cast packets. When a uni-castpacket is being transferred from transport layer 615 towards applicationlayer 611, multi-cast layer 613 can ensure that the uni-cast packet isdelivered to application layer 611 after a corresponding multi-castpacket (e.g., multi-cast packet 626) of the same priority. Similarly,when a uni-cast packet is being transferred from application layer 611towards transport layer 615, multi-cast layer 613 can ensure that theuni-cast packet is delivered to data framing layer 622 after acorresponding multi-cast packet (e.g., multi-cast packet 627) of thesame priority.

The method 400 includes an act of receiving repair conferencing datafrom the parent computer system (act 410). Act 410 can include a childcomputer system receiving repair conferencing data for repairingconferencing data that was not sufficiently received by the childcomputer system. Repair conferencing data can be received via uni-castor multi-cast. For example, if intermediate computer system 212 receivedmulti-cast packet 282 but leaf computer systems 222 did not, a TCPconnection (e.g., that was created when the leaf computer system 222joined electronic conference 270) can be re-used over link 243 tore-transmit conferencing data 252. This conserves network resourcessince no TCP connection need be established over link 241 to repairconferencing data at leaf computer system 222. Accordingly, embodimentsof the present invention can more reliably deliver conferencing datathrough recovery via connection-oriented protocols, while stillrealizing potential bandwidth savings and reduced latency associatedwith multi-cast.

FIG. 5 illustrates an example flow chart of a method 500 for adjusting amulti-cast send rate. The method 500 will be described with respect tothe computer systems in network architecture 200.

The method 500 includes an act of identifying a current send rate forconferencing data (act 501). Act 501 can include a root computer systemidentifying a current send rate (e.g., four kilobytes per second, tenkilobytes per second, one megabyte per second, etc.) for sendingconferencing data to computer systems participating in a multi-castsession. The current send rate is a rate the root computer system willtransmit conferencing data (e.g., by configuring a packet size andtransmission interval) to other computer systems participating in themulti-cast conferencing session. For example, root computer system 202can identify a current send rate for transmitting conferencing data tocomputer systems participating in multi-cast session 250. When amulti-cast session is initially established a current send rate can bean initial send rate having a decreased likelihood of causing congestionon links of a multicast session (e.g., links 241, 242, 243, 244, 245,and 246), such as, for example, one kilobyte per second.

The method 500 includes an act of identifying a next sequence number(502). Act 502 can include a root computer system identifying the nextsequence number that is to be associated with the next transmittedmulti-cast packet. For example, root computer system 202 can identifyingthe sequence number that is to be associated with the next multi-castpacket transmitted to computer systems participating in multi-castsession 250.

The method 500 includes an act of selecting a rate change packetsequence number a specified threshold greater than the next packetsequence number (act 503). Act 503 can include a root computer systemselecting a rate change packet sequence number that indicates when theroot computer system can potentially adjust the current send rate. Forexample, root computer system 202 can select a rate change sequencenumber that indicates when computer system 202 can potentially adjustthe current send rate for multi-cast session 250.

A specified threshold (e.g. a specified number of packets) can be set sothat the root computer system (e.g., computer system 202) has anopportunity to receive at least one acknowledgment message from each ofthe root computer system's immediate child computer systems (i.e.,intermediate computer systems 212 and 213). Thus, an appropriatespecified threshold can be set so that the difference of the next packetsequence number subtracted from the rate change packet sequence numberis greater than the root computer system's ACK window parameter value.An appropriate specified threshold provides an interval for immediatechild computer systems to send acknowledgment messages acknowledging allthe multi-cast packets in a sequence of multi-cast packets receivedwithin the root computer system acknowledgment window. For example, ifan ACK window parameter value were 5 (representing that anacknowledgment message is to be sent after the reception of every 5multi-cast packets), a specified threshold could be set to at least 6multi-cast packets. Accordingly, if a next sequence number were 17, arate change packet sequence number could be set to at least 23.

The method 500 includes an act of transmitting at least a nextmulti-cast packet having the next packet sequence number (act 504). Act504 can include a root computer system transmitting a next multi-castpacket in accordance with the current send rate. For example, rootcomputer systems 202 can transmit a next multi-cast packet to computersystem participating in multi-cast session 250 in accordance with thecurrent send rate for multi-cast session 250. It may be that a sequenceof multi-cast packets (e.g., packets within an acknowledgment window),including the next multi-cast packet and a rate change multi-cast packethaving the rate change packet sequence number, is transmitted.

The method 500 includes an act of adjusting the send rate based at leaston whether the one or more immediate child computer systems indicatedreception of the next multi-cast packet (act 505). Act 505 can include aroot computer system decreasing the current send rate in response toreceiving a negative acknowledgment message (or no message at all) froman immediate child computer system. For example, root computer system202 can decrease the current send rate for multi-cast session 250 inresponse to receiving a negative acknowledgment message fromintermediate computer system 212 or 213. It may be that an immediatechild computer system sends a negative acknowledge or is prevented fromsending a message at all due to network congestion.

After a reduction in send rate, the root computer system can reset arate change sequence number to verify that the decreased send rate issustainable. When a root computer system receives negativeacknowledgment messages from a plurality of immediate child computersystems, the root computer may decrease the current send rate the sameamount it would have reduced the send rate if one negativeacknowledgment was received. This reduces the potential of dropping thecurrent send rate to a rate significantly below a sustainable send rate.

On the other hand, act 505 can include a root computer system increasingthe current send rate in response to receiving acknowledgment messagesfrom each immediate child computer system. For example, root computersystem 202 can increase the current send rate for multi-cast session 250in response to receiving acknowledgment messages from both intermediatecomputer system 212 and intermediate computer system 213. Accordingly, aroot computer system can adjust a send rate to compensate for changes inthe transmission characteristics (e.g., available bandwidth and latency)of networks used to deliver multi-cast packets.

A root computer system may increase and/or decrease a send rate by apredetermined amount based on a previous adjustment in send rate. Table3 represents an example of how a send rate can be adjusted.

TABLE 3 Previous Adjustment To Increase To Decrease No Change Double Cutby Quarter/Linear Decrease Double Double Cut by Half Increase a QuarterIncrease a Quarter/Linear Cut by Quarter/Linear Increase Decrease LinearIncrease Increase a Quarter/Linear Linear Decrease Increase Cut by HalfIncrease by a Quarter Cut by Quarter/Linear Decrease Cut by a QuarterIncrease by a Quarter Cut by Quarter/Linear Decrease Linear DecreaseIncrease a Quarter/Linear Cut by Quarter/Linear Increase Decrease

When it is determined that a current send rate is to be adjusted, aprevious adjustment is considered. For example, when it is determinedthat the send rate is to be increased (as a result of receivingappropriate acknowledgment messages) and a previous adjustment wascutting the send rate in half, the current send rate can be increased bya quarter. A no change previous adjustment can occur when adjusting aninitial send rate.

The term “Increase By A Quarter/Linear Increase” represents that acurrent send rate can be increased by a quarter or a smaller amount(e.g., 1/16^(th)). When a current send rate is less than the previouslyrecorded highest send rate, the root computer system can increase thesend rate by a quarter. Below a previously recorded highest send rate,increasing by a quarter may be appropriate since there is someconfidence that an increased send rate near the previously recordedhighest send rate will not cause network congestion. On the other hand,when a current send rate is greater than the previously recorded highestsend rate, the root computer system can linearly increase the send rate.Above a previously recorded highest send rate, there may be no way todetermine if an increased send rate will cause network congestion.Accordingly, a more conservative linear increase may be appropriate.

Similarly the term “Cut By A Quarter/Linear Decrease” represents that acurrent send rate can be decreased by a quarter or a smaller amount(e.g., 1/16^(th)). When the number of lost multi-cast packets reportedinside a negative acknowledgment message is less than a cutoff limit(e.g., 4 multi-cast packets), the root computer system can linearlydecrease the current send rate. On the other hand, when the number oflost multi-cast packets reported inside a negative acknowledgmentmessage is more than the cutoff limit, the root computer system deceasethe current send rate by a quarter. Use of a cutoff limit increases thechance of making an appropriate adjustment based on the severity ofpacket loss. When a decreased number of multi-cast packets are lost(e.g., 1 or 2), a linear decrease may sufficiently reduce networkcongestion enough to mitigate further packet loss. When an increasednumber of packets are lost, such as, for example, when a burst ofpackets are lost, amore significant decrease in the current send ratemay be needed to sufficiently reduce network congestion.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges, which come within the meaning and range of equivalency of theclaims, are to be embraced within their scope.

1. A method comprising: receiving, by a computing device at a designatedmulticast address of a multicast session from a sender of multicastpackets of the multicast session in response to the computing devicejoining the multicast session, a multicast packet of the multicastsession; checking, by the computing device, a source address of thereceived multicast packet and, if the source address does not match anetwork address of the sender, discarding the multicast packet and, ifthe source address does match the network address of the sender, sendinga status message indicating that the computing device joined themulticast session and received the multi-cast packet.
 2. The method ofclaim 1 further comprising verifying, by the computing device based on anetwork interface configuration, that the multicast packets from thesender are associated with the multicast session.
 3. The method of claim1 wherein the received multicast packet indicated to the computingdevice that a previously received invite message included informationsufficient for the joining.
 4. The method of claim 1 further comprisingreceiving, by the computing device in response to the sent statusmessage, a message comprising a sequence number that will be associatedwith a next sent multicast packet of the multicast session.
 5. Themethod of claim 4 wherein the received sequence number is configured forenabling the computing device to determine that various multicastpackets of the multicast session were not fully received by thecomputing device, wherein not fully received includes not received atall.
 6. The method of claim 5 further comprising sending, by thecomputing device, a negative acknowledgement message that indicates thatthe various multicast packets of the multicast session were not fullyreceived by the computing device.
 7. The method of claim 6 furthercomprising receiving, by the computing device in response to the sentnegative acknowledgement message via unicast instead of multicast, dataof the multicast session that was included in the various multicastpackets that were not fully received by the computing device.
 8. Atleast one computer storage device storing computer-executableinstructions that, when executed by a computing device, cause thecomputing device to perform a method comprising: receiving, by thecomputing device at a designated multicast address of a multicastsession from a sender of multicast packets of the multicast session inresponse to the computing device joining the multicast session, amulticast packet of the multicast session; checking, by the computingdevice, a source address of the received multicast packet and, if thesource address does not match a network address of the sender,discarding the multicast packet and, if the source address does matchthe network address of the sender, sending a status message indicatingthat the computing device joined the multicast session and received themulti-cast packet.
 9. The at least one computer storage device of claim8, the method further comprising verifying, by the computing devicebased on a network interface configuration, that the multicast packetsfrom the sender are associated with the multicast session.
 10. The atleast one computer storage device of claim 8 wherein the receivedmulticast packet indicated to the computing device that a previouslyreceived invite message included information sufficient for the joining.11. The at least one computer storage device of claim 8, the methodfurther comprising receiving, by the computing device in response to thesent status message, a message comprising a sequence number that will beassociated with a next sent multicast packet of the multicast session.12. The at least one computer storage device of claim 11 wherein thereceived sequence number is configured for enabling the computing deviceto determine that various multicast packets of the multicast sessionwere not fully received by the computing device, wherein not fullyreceived includes not received at all.
 13. The at least one computerstorage device of claim 12, the method further comprising sending, bythe computing device, a negative acknowledgement message that indicatesthat the various multicast packets of the multicast session were notfully received by the computing device.
 14. The at least one computerstorage device of claim 13, the method further comprising receiving, bythe computing device in response to the sent negative acknowledgementmessage via unicast instead of multicast, data of the multicast sessionthat was included in the various multicast packets that were not fullyreceived by the computing device.
 15. A system comprising: a computingdevice configured for receiving, at a designated multicast address of amulticast session from a sender of multicast packets of the multicastsession in response to the computing device joining the multicastsession, a multicast packet of the multicast session; the computingdevice further configured for checking a source address of the receivedmulticast packet and, if the source address does not match a networkaddress of the sender, the computing device further configured fordiscarding the multicast packet and, if the source address does matchthe network address of the sender, the computing device furtherconfigured for sending a status message indicating that the computingdevice joined the multicast session and received the multi-cast packet.16. The system of claim 15, the computing device further configured forverifying, based on a network interface configuration, that themulticast packets from the sender are associated with the multicastsession.
 17. The system of claim 15 wherein the received multicastpacket indicated to the computing device that a previously receivedinvite message included information sufficient for the joining.
 18. Thesystem of claim 15, the computing device further configured forreceiving, in response to the sent status message, a message comprisinga sequence number that will be associated with a next sent multicastpacket of the multicast session.
 19. The system of claim 18 wherein thereceived sequence number is configured for enabling the computing deviceto determine that various multicast packets of the multicast sessionwere not fully received by the computing device, wherein not fullyreceived includes not received at all.
 20. The system of claim 19further comprising: the computing device further configured for sendinga negative acknowledgement message that indicates that the variousmulticast packets of the multicast session were not fully received bythe computing device; and the computing device further configured forreceiving, in response to the sent negative acknowledgement message viaunicast instead of multicast, data of the multicast session that wasincluded in the various multicast packets that were not fully receivedby the computing device.